so after looking at this closer, it seems that this will break this:

basically the (.*) would capture the args as well and then inject them as $1 again, but then $is_args$args would add the args again, so we would have double args that would break the redirect :/

so I think this PR would break Backwards-Compatibility.
Maybe we should do it this way:

    map $host$uri $redirectdomain {
        include /etc/nginx/redirects-map.conf;
    }
    map $host$uri$args $redirectdomain {
        include /etc/nginx/redirects-map-args.conf;
    }

so that people that want to use this, can add their redirects with args to /etc/nginx/redirects-map-args.conf ?

@Schnitzel that solution would definitely work for us too, having 2 separate maps

Having the separate args-map would require it to be included into the repo and copied into the image as per
https://github.com/uselagoon/lagoon-images/blob/main/images/nginx/Dockerfile#L38

Can you duplicate https://github.com/uselagoon/lagoon-images/blob/main/images/nginx/redirects-map.conf with a couple of examples?

@tobybellwood all done - map hierarchy @ nginx.conf might need some more testing

helper still needed

If I understand this PR correctly, this is about enabling Nginx to have a map file built in that would allow redirecting based not only on host and URI, but query parameters as well.

99% of the redirects I do in Nginx are not based on query params, but I can see the possibility where this would be useful I guess (e.g. legacy site migration that uses query params to Lagoon).

What I would like to see

• clearer explanations in the redirects-map-args.conf file with when you would use this file over the other map file redirects-map.conf.

Questions

• Is args the best terminology here? I almost always refer to these as query parameters. Perhaps the map file would be best named redirects-with-query-parameters-map.conf or something?